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Simulations  have  been  used  during  exercises  within  analysis  and  planning  cells  for  much  of  the 
past  decade.  However,  the  usefulness  of  such  simulations  is  dependent  on  the  ability  to  rapidly 
enter  data  from  the  tactical  picture  into  the  simulation,  for  use  as  a  starting  point  for  running 
analyses.  Current  methods  for  pulling  in  such  C4ISR  data  rely  on  manual  data  entry  that  can 
introduce  errors  and  take  significant  time  to  accomplish.  This  paper  discusses  an  approach  that 
allows  automated  initialization  of  simulations  that  takes  advantage  of  an  existing  High  Level 
Architecture  (HLA)  Runtime  Infrastructure  (RTI)  interface  within  the  Global  Command  and 
Control  System  (GCCS). 


During  the  Navy's  Global  2001  wargaming  exercise,  this  approach  was  used  to  rapidly  initialize 
the  Naval  Simulation  System  (NSS)  for  use  in  performing  Course  of  Action  (CO A)  analysis  in  the 
Naval  Forces  (NAVFOR)  cell.  The  introduction  of  an  automated  feed  from  GCCS  not  only 
reduced  the  initialization  time  required  for  NSS,  but  also  allowed  analysts  to  evaluate  more 
complex  scenarios  with  larger  track  groups.  A  similar  approach  using  the  same  GCCS  HLA 
interface  was  successfully  demonstrated  with  the  Integrated  Theater  Engagement  Model  (ITEM) 
as  part  of  exercise  RSOI  in  April  02  for  United  States  Forces  Korea  (USFK). 

1.0  Background 

Increasingly,  simulations  are  being  used  during  military  exercises  and  operations  by  the  planning 
and  analysis  staffs  to  conduct  analysis.  Different  commands  rely  on  a  variety  of  simulation 
applications  for  this  purpose.  Among  the  simulation  systems  currently  used  to  support  such 
analysis  are  ITEM,  NSS,  THUNDER,  and  the  Tactical  Warfare  (TACWAR)  simulation. 


One  of  the  biggest  drawbacks  to  using  such  simulations  for  planning  and  COA  analysis  is  the 
inability  to  readily  load  data  from  C4ISR  systems  into  such  tools,  without  the  need  for  manual 
data  entry.  This  creates  long  delay  times  to  initialize  the  simulation  and  generates  data  errors 
through  a  manual  entry  process.  In  many  cases,  the  C4ISR  system  is  not  collocated  in  the  cells 
where  the  analysis  is  being  performed,  complicating  the  problem  even  further. 


Over  the  past  decade  considerable  strides  have  been  made  in  the  automation  of  C4ISR  and 
simulation  interfaces.  So  why  does  this  disconnect  exist  in  data  initialization  of  simulations  from 


C4ISR  systems?  The  primary  reason  is  that  C4ISR-Simulation  interface  advances  have  focused 
primarily  on  the  problem  of  stimulating  C4ISR  systems  with  content  provided  by  simulations  as 
part  of  command  post  training  exercises.  While  not  trivial,  this  problem  has  been  largely  solved 
through  the  design  of  message  generators  that  provide  the  required  content  in  the  appropriate 
format  of  the  C4ISR  system.  It  has  not  been  necessary  to  make  modifications  to  the  C4ISR 
system  itself  -  almost  all  of  the  changes  to  improve  C4ISR-Simulation  interoperability  have 
occurred  on  the  side  of  the  simulation  system. 

Once  the  simulation  messages  are  received  at  the  C4ISR  system,  they  are  parsed  and  the  content 
is  loaded  into  the  system  database,  as  it  would  be  with  an  actual  C4ISR  message.  The  retrieval  of 
this  data,  for  purposes  of  initializing  an  analysis  simulation  does  require  that  the  C4ISR  system  be 
modified  in  order  to  be  able  to  extract  this  data  and  use  it  in  a  simulation.  For  the  most  part, 
C4ISR  systems  have  been  unwilling  to  make  such  modifications,  in  part  because  their 
configuration  management  is  tightly  controlled  to  ensure  that  no  unnecessary  software  processes 
are  loaded  onto  the  system  that  could  lead  to  problems  in  operating  such  "go-to-war"  systems. 

2.0  Approach 

While  the  problem  of  stimulating  C4ISR  systems  from  simulations  has  been  largely  solved,  it  has 
led  to  the  development  of  literally  hundreds  of  C4ISR-simulation  interfaces.  Many  of  these 
interfaces  replicate  functionality  between  systems  -  for  example,  each  interface  has  its  own  unique 
message  generator  capability  built  in,  even  though  similar  formats  are  generated  across  the  many 
interfaces  (VMF,  USMTF,  Link  16,  etc.).  The  large  number  of  such  interfaces  is  costly  to 
maintain  and  has  led  to  an  increased  effort  within  the  services  and  DoD  to  standardize  C4ISR- 
simulation  interfaces  where  possible.  Therefore,  any  approach  to  addressing  the  inverse  problem 
of  simulation  initialization  from  C4ISR  system  data  should  take  advantage  of  C4ISR  and 
simulation  standards  to  the  greatest  degree  possible.  This  means  leveraging  common  architecture 
solutions  of  the  Defense  Information  Infrastructure  Common  Operating  Environment  (DII  COE) 
and  the  High  Eevel  Architecture  (HEA). 

Secondly,  the  approach  to  initialization  should  be  "data  driven"  and  not  "message  driven".  The 
goal  of  rapid  initialization  is  to  take  the  perceived  state  of  the  operation  as  it  exists  in  the  C4ISR 
system  and  transfer  it  as  quickly  as  possible  into  the  simulation.  A  message-based  solution  that 
requires  the  simulation  to  parse,  correlate,  and  properly  interpret  C4ISR  messages  places  an 
additional  burden  of  processing  on  that  simulation  and  replicates  a  function  already  being  handled 
by  the  C4ISR  system.  A  more  direct  approach  would  be  to  transfer  the  data  that  comprises  the 
correlated  picture  in  the  C4ISR  system  directly  to  the  simulation. 

The  initialization  solution  has  to  be  straightforward  to  implement.  As  the  target  audience  for 
simulation  support  tools  is  the  military  planner  and  analyst,  C4ISR-to-simulation  solutions  must 
be  built  so  that  they  can  be  easily  implemented.  If  the  solution  requires  a  large  support  footprint 
of  contractors  it  cannot  be  implemented  in  a  warfighting  environment.  Ideally,  such  solutions 
could  be  used  directly  by  the  user  as  part  of  their  normal  interactions  with  their  C4ISR  system. 

Einally,  the  solution  has  to  fit  into  the  constraints  of  the  exercise  or  operational  setting.  The 
introduction  of  a  complex  system  of  hardware  and  software  will  generally  not  be  tolerated  in  an 
operational  setting  where  space  is  at  a  premium.  Also,  such  complex  solutions  have  a  larger 


probability  of  failure  that  could  impact  other  operational  systems,  which  is  why  they  are  usually 
discouraged  on  an  operational  network. 

3.0  GCCS  Ambassador 


Luckily,  one  of  the  key  components  to  address  automated  initialization  already  existed  at  the  time 
this  work  was  undertaken.  As  part  of  previous  C4ISR- Simulation  interoperability  experiments, 
the  Naval  Research  Laboratory  (NRL)  had  already  developed  a  GCCS  HLA-compliant  interface 
(known  as  the  "GCCS  Ambassador")  that  allowed  simulation  data  to  be  sent  via  the  RTI  and 
deposited  into  the  GCCS  Track  Database  Manager  (TDBM).  This  interface  was  originally 
developed  to  work  with  the  Joint  Theater  Level  Simulation  (JTLS),  an  aggregate-level  simulation 
of  air,  ground,  and  sea  operations  used  primarily  by  the  Joint  Warfighting  Center  (JWFC)  in  Joint 
training  exercises.  Details  of  this  federation  can  be  found  in  [Nielsen  et  al.,  1998]. 

The  TDBM  contains  information  on  all  correlated  tracks  that  have  been  received  by  GCCS  as 
either  Over-the-Horizon  Gold  (OTH-G)  or  Link- 16  messages  or  other  types  of  sensor  reports. 
The  TDBM  is  the  underlying  database  that  provides  data  to  the  GCCS  Common  Operating 
Picture  (COP).  Figure  1  shows  a  graphical  depiction  of  the  interactions  between  the  GCCS 
Ambassador,  the  RTI,  the  TDBM,  and  the  COP  all  within  a  single  GCCS  hardware  platform. 

Because  of  its  interface  to  the  TDBM,  the  GCCS  Ambassador  can  either  write  to,  or  read  from, 
the  TDBM  based  on  data  it  either  receives  or  sends  across  the  RTI.  This  is  exactly  the  type  of 
automated  interface  that  satisfies  the  rapid  initialization  criteria  described  in  the  previous  section. 
However,  in  order  to  realize  this  interface  it  requires  that  a  portion  of  the  RTI  process  be  able  to 
execute  on  the  GCCS  hardware  platform  itself.  While  this  could  have  implications  for  disrupting 
other  GCCS  processes,  during  demonstrations  of  previous  work  involving  the  JTLS-GCCS 
federation,  no  noticeable  impact  occurred  to  other  GCCS  processes  as  a  result  of  running  the  RTI 
on  the  GCCS  platform.  Since  then,  the  GCCS  Ambassador  has  been  extended  to  work  with  the 
Naval  Simulation  System  (NSS)  [Lutz  et  al.,  1999]  ,  and  Pegasus  federation  [Layman  et  al., 
2001]  ,  without  any  noticeable  impact  on  other  GCCS  processes. 
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Figure  1.  GCCS  Ambassador  Component  Architecture  [Lutz  et  al.,  1999] 


4.0  GCCS-NSS 


During  the  execution  of  Navy’s  Global  2000  wargaming  exercise,  the  previously  mentioned 
limitations  on  initialization  of  COA  simulations  for  analysis  with  manual  inputs  became  apparent. 
NSS  was  used  during  Global  2000  in  the  White  Cell,  to  help  with  COA  analysis  and  exercise 
arbitration.  In  this  mode,  NSS  users  would  manually  input  the  initial  location,  speed,  and  heading 
information  of  unit  tracks  that  were  desired  in  the  analysis.  This  approach  would  often  take  an 
hour  or  more,  depending  upon  the  number  of  units  or  tracks  included  in  the  scenario.  Because  of 
the  amount  of  time  required,  and  the  difficulty  in  manually  initializing  NSS  in  this  manner,  COA 
scenarios  were  often  of  limited  size  and  complexity,  with  typically  no  more  than  20  tracks  as  part 
of  the  COA  analysis. 

4.1  GCCS-NSS  Design 

The  key  to  fixing  the  initialization  problem  was  in  the  recognition  that  the  previous  HLA  work 
involving  NSS  and  GCCS  could  be  applied  in  reverse.  Because  the  GCCS  RTI  interface  was  tied 
directly  to  the  TDBM,  this  allowed  for  ready  access  to  the  actual  data  elements  that  provided  the 
operational  view  in  the  GCCS  COP. 

The  RTI  interface  into  GCCS  provides  access  to  all  of  the  data  elements  in  the  TDBM. 
Therefore,  the  Federation  Object  Model  (FOM)  for  NSS-GCCS  is  based  heavily  on  the  data 
elements  in  the  TDBM.  In  fact,  the  original  FOM  that  existed  between  GCCS  and  NSS  that  was 
used  to  populate  the  TDBM  was  re-used  with  very  few  alterations  to  initialize  NSS. 

Although  air  track  data  is  available  in  the  TDBM,  it  was  decided  not  to  publish  or  use  this  data  as 
part  of  the  federation  execution.  This  decision  was  made,  in  part,  because  of  the  speed  at  which 
aircraft  travel,  they  would  quickly  ‘dead-reckon’  out  of  the  area.  Combined  with  the  fact  that 
aircraft  missions  rely  on  dedicated  launch  and  landing  sites  and  perform  relatively  complex  motion 
and  operational  plans,  it  did  not  make  sense  to  pass  this  information  over  to  NSS  as  part  of  the 
COA  formulation.  Even  with  the  increase  in  speed  in  initializing  NSS,  by  the  time  that  multiple 
runs  were  performed  and  the  data  analyzed  the  ability  to  modify  tasking  associated  with  aircraft 
missions  would  not  be  possible. 

One  of  the  technical  challenges  addressed  during  implementation  of  this  federation,  was  in 
handling  differences  in  naming  convention  between  NSS  and  GCCS.  Prior  to  the  initialization 
process,  NSS  had  been  "pre-loaded"  with  an  exercise  database  that  contained  the  Unit  Order  of 
Battle  (UOB)  and  details  on  the  capabilities  of  these  units  for  the  Global  2000  exercise. 
However,  as  the  track  data  coming  into  GCCS  is  derived  from  a  separate  simulation  that  is 
driving  the  exercise,  in  most  cases  the  GCCS  data  did  not  directly  match  what  was  in  NSS.  To 
resolve  this  mapping,  NSS  buffered  the  RTI  data  prior  to  forwarding  it  on  to  the  simulation 
process  and  performed  pair  matching  between  this  track  data  and  its  NSS  database.  NSS 
employed  a  mapping  table  that  determined  the  default  mapping  from  GCCS  to  NSS.  For 
example,  any  GCCS  track  with  a  Threat  value  of  “FRD”  (friendly)  would  be  mapped  to  the  NSS 
“Blue”  alliance.  The  user  could  either  accept  the  mapping  choices  or  individually  change  any 
mapping  target.  The  mapping  process  involved  associating  a  GCCS  track  with  an  NSS  alliance 
(Blue,  Red,  White,  etc.),  an  NSS  force  commander,  an  NSS  asset  class,  and  an  NSS  tactics  table. 
The  mapping  function  has  a  memory  feature  so  that  it  remembers  a  mapping.  For  example,  if  the 


analyst  maps  GCCS  Track  T  to  the  NSS  set  (Alliance  A,  Force  Commander  B,  Name  C,  Asset 
Class  D,  Tactics  Table  E),  then  that  mapping  will  be  “remembered”  and  will  be  automatically 
displayed  as  the  default  the  next  time  the  analyst  imports  CCCS  Track  A. 

Another  configuration  issue  for  Clobal  2001  was  the  requirement  to  work  with  the  Navy  variant 
of  GCCS,  or  GCCS -Maritime  (GCCS-M).  GCCS-M  only  runs  under  the  HP  environment,  but 
there  is  no  version  of  the  RTI  that  can  run  under  HPUX.  This  problem  was  addressed  through 
the  use  of  the  auto-forwarding  function  within  GCCS-M.  Messages  were  generated  by  the  C4I 
Gateway,  an  OTH-Gold  message  generator  linked  with  the  Joint  Semi-Automated  Forces  (JSAF) 
simulation,  and  sent  to  GCCS-M  where  they  were  auto-forwarded  to  a  GCCS  machine.  The 
GCCS  machine  was  configured  to  run  Sun  Solaris,  allowing  it  to  run  both  the  GCCS  Ambassador 
and  RTI  process.  This  auto-forwarded  data  was  then  consolidated  on  the  TDBM  on  the  GCCS 
Sun  machine  and  sent  via  the  RTI  to  NSS.  A  diagram  showing  the  configuration  of  processes  for 
this  exercise  is  shown  in  Figure  2.  The  technical  details  surrounding  this  implementation  can  be 
found  in  [Prochnow  et  al.,  2001] 


Figure  2:  Simulation  Architecture  for  Global  2001  [Prochnow  et  al.,  2001]. 

An  interesting  operational  challenge  in  using  the  GCCS-NSS  interface  was  in  dealing  with 
"unknown"  (identified  as  neither  Blue  or  Red  forces)  tracks  in  the  GCCS  COP.  Such  tracks  often 
arise,  due  to  insufficient  information  received  from  various  data  sources  that  feed  the  COP.  In 
such  instances,  unknown  tracks  in  GCCS  are  transmitted  are  assigned  a  value  of  "unknown"  to 
the  "threat"  attribute,  as  they  are  transmitted  to  NSS  across  the  RTI.  Upon  receipt  in  NSS,  they 
may  be  assigned  an  alliance  and  some  sort  of  general  tactics,  depending  on  the  nature  of  the  COA 
that  is  to  be  conducted  (worst  case,  or  optimal  case). 

4.2  Implementation  in  Global  01 

During  Global  2001,  the  role  of  NSS  expanded  beyond  the  traditional  Red  and  White  Cell 
support,  to  provide  COA  analysis  support  to  the  Blue  Cell  or  the  NAVFOR  Commander.  In  this 
role,  the  ability  to  rapidly  initialize  an  NSS  study  using  the  GCCS  Ambassador  and  provide  timely 
results  was  key  to  supporting  NAVFOR  planners  and  decision-makers.  Unlike  previous 
wargames,  the  analyses  were  more  robust  and  used  a  larger  number  of  tracks  (typically  over  five 
hundred)  which  more  accurately  represented  the  relatively  complex  COP. 


During  the  wargame,  the  NAVFOR  Commander  would  typically  direct  his  staff  to  consider 
various  options,  including  use  of  specific  platforms  (ships/aircraft),  movement  of  assets,  or 
specific  actions  against  the  enemy  (such  as  electronic  attack).  As  the  staff  developed  CO  As  to 
consider,  the  NSS  operators/planners  would  liaison  with  the  NAVFOR  staff  to  determine  which 
general  COAs  were  being  considered,  pass  that  information  verbally  to  the  NSS  operator,  who 
would  then  use  the  GCCS  Ambassador  to  pull  in  COP  tracks  for  the  area  of  interest.  This  process 
was  so  responsive  that  before  long,  rather  than  having  to  request  information  from  planners  to 
initiate  CO  A  studies,  NSS  operators  found  that  the  staff/planners  would  come  to  them,  asking  for 
a  COA  analysis.  Additionally,  by  formulating  COAs  so  that  they  could  be  simulated  and  studied 
with  an  analytic  decision  aid  like  NSS,  the  details  of  COAs  under  consideration  were  more  clearly 
specified. 

The  use  of  the  GCCS  Ambassador  allowed  the  NSS  operator  to  quickly  pass  track  data  to  NSS, 
setup  appropriate  tactics  and  communications,  conduct  multiple  Monte-Carlo  runs,  and  provide 
more  timely  results  to  planners  and  decision-makers.  As  a  result,  NSS  operator  workload  was 
significantly  reduced  and  in  most  cases  NSS  COA  analysis  results  were  available  and  presented  to 
decision-makers  in  time  to  affect  the  selection  of  a  particular  COA.  In  many  cases,  after  the  NSS 
operator  had  built  the  COA  (setting  up  appropriate  tactics)  the  GCCS  COP  would  refresh  NSS 
one  last  time  -  allowing  the  most  accurate  picture  of  the  current  situation  to  be  used  in  initializing 
the  COA. 

Since  less  time  was  spent  on  manually  inputting  track  data,  more  time  was  available  to  consider 
additional  COAs  or  refinements  to  COAs  or  for  planners  to  ask  questions  hke,  “What  if  I  moved 
this  ship  here?”  or  “What  if  we  denied  the  Red  Force's  use  of  this  airfield/aircraft?”  It  should  be 
noted  that  the  use  of  NSS  in  this  context  was  not  a  substitute  for  sound  military  judgment.  NSS 
was  used  as  COA  decision  aid,  which  provided  decision-makers  with  a  better  understanding  of 
the  underlying  factors  contributing  to  a  COA  outcome  and  more  confidence  in  the  likely  success 
of  a  decided-upon  COA. 

Some  interesting  operational  lessons  were  identified  through  the  use  of  the  GCCS-NSS  linkage. 
One  of  these  was  the  importance  of  communication  and  coordination  between  the 
planner/decision-maker  and  NSS  operator.  During  the  exercise,  it  was  quickly  realized  that  the 
COA  initialization  process  could  be  inefficient  if  key  elements  or  details  of  a  COA  being 
considered  were  not  passed  to  the  NSS  operator.  In  some  cases,  salient  information  in  the  COA 
was  omitted  during  the  setup  only  to  be  discovered  several  hours  later  after  multiple  runs  had 
been  performed.  Inputting  the  missing  detail  was  usually  straightforward,  but  required  the 
multiple  COA  runs  to  be  performed  again.  The  solution  to  this  problem  was  to  review  a 
standardized  COA  analysis  study  checklist  prior  to  run  execution.  This  checklist  included  such 
information  such  as:  Scenario  Name,  Description,  Start  Time  /  Duration,  What  If  /  Excursions, 
Blue/RedAVhite  Assets  (including  Type,  Number,  Weapons,  Sensors,  Location,  Mission,  ROE  / 
Tactics),  and  results  or  questions  to  be  answered. 

Another  unforeseen  consequence  of  using  the  GCCS-NSS  application  was  that  hundreds  of  tracks 
could  now  be  “pulled  into”  NSS  immediately,  which  increased  the  size  and  complexity  of  the 
scenarios  being  evaluated.  In  some  cases,  the  limitations  on  computer  processing  coupled  with 
the  need  to  run  multiple  replications  to  form  a  valid  statistical  sample,  required  long  execution 
times  -  sometimes  overnight.  A  potential  solution  to  this  problem  would  be  to  export  the  GCCS 


COP  data  to  a  “reachback”  analysis  center,  where  adequate  computing  power  is  present.  Such 
resources  as  the  high  performance  computers  located  at  Maui,  Hawaii,  may  have  the  sufficient 
processing  power  to  serve  COA  analysis  needs  for  an  entire  theater.  More  discussion  of 
“reachback”  potential  for  this  technology  is  contained  in  Section  7.2. 

While  the  availability  of  GCCS  COP  data  significantly  improved  initialization  time  and  accuracy,  it 
was  still  necessary  for  the  NSS  operator  to  manually  “fill  in”  enemy  intentions  and  estimate  the 
locations  of  unobserved  (but  known  to  exist)  units,  such  as  submarines.  This  requirement  added 
to  the  operator  workload  and  increased  the  amount  of  time  that  it  took  to  run  an  analysis  and 
provide  results  to  decision-makers.  The  use  of  additional  C4ISR  data  sources,  beyond  the  GCCS 
COP,  could  help  to  improve  the  completeness  of  the  initialization  (see  Section  7.1). 

With  the  improving  use  of  simulation  aids,  such  as  NSS,  during  the  planning  and  analysis  portions 
of  military  operations,  it  is  likely  that  there  will  a  migration  away  from  analyst-based  support 
towards  more  direct  use  by  fleet  operators.  As  a  result,  it  will  be  critically  important  to  train  these 
fleet  operators  and  planners  to  accurately  use  and  realistically  interpret  the  results  from  these 
types  of  analytic  decision  aids. 

A  final  operational  consideration  for  the  future  will  be  in  dealing  with  the  real  world  problem  of 
track  latency.  Since  the  GCCS  COP  was  artificially  generated  using  the  JSAF,  none  of  the  track 
reports  were  significantly  delayed.  If  used  in  an  operational  environment  where  GCCS  tracks 
might  be  delayed  by  minutes  or  hours,  it  may  be  necessary  to  filter  or  discard  tracks  that  did  not 
meet  specified  criteria  for  timeliness  or  updates. 

4.3  Implementation  in  NORWESTPAC  Exercise  02 

During  March  02,  the  GCCS-NSS  application  was  used  during  the  Navy's  NORWESTPAC 
exercise  at  NWC,  in  Newport,  RI.  The  use  of  the  federation,  prior  to  the  start  of  the  exercise, 
allowed  the  base  game  scenario  in  NSS  to  be  constructed  in  a  single  day  -  a  process  that  typically 
takes  an  entire  week.  In  addition  to  reducing  the  initial  scenario  development  time  down  to  a 
single  day,  the  execution  of  simulation  runs  during  the  exercise  was  done  in  under  an  hour.  This 
base  scenario  involved  over  700  tracks  that  were  updated  periodically  over  3  days  of  game  play. 
The  federation  was  up  continuously  for  all  three  days  with  only  minor  hiccups  that  were  very 
apparent  and  easily  recovered  from. 

While  NSS  was  not  used  directly  in  this  exercise  for  COA  development  and  analysis,  the  use  of 
the  GCCS-NSS  linkage  highlighted  another  important  capability  of  this  federation.  During  this 
exercise  the  GCCS  Reconstruction  Logger  (or  "Recon"  tool)  was  used,  allowing  for  the  capture 
of  all  track  data  corresponding  to  OTH-Gold  messages  received  by  GCCS.  The  recording  of  this 
information,  along  with  the  use  of  NSS,  allows  for  simplified  post  exercise  analysis.  At  the  end  of 
this  exercise,  the  Recon  data  was  sent  to  CINCPACFLT  for  their  post-game  analysis  efforts  and 
to  serve  as  baseline  data  for  other  studies  that  they  are  conducting.  CINCPACFLT  recently 
completed  installation  of  the  GCCS-NSS  capability  at  their  location,  so  that  they  will  be  able  to 
initialize  NSS  for  analysis  runs  based  on  the  same  set  of  data  that  was  used  in  the 
NORWESTPAC  exercise. 


5.0  GCCS-ITEM 


During  a  visit  to  United  States  Forces  Korea  (USFK)  in  February  2001,  personnel  from  the 
Defense  Modeling  and  Simulation  Office  (DMSO)  held  discussions  with  the  USFK  planning  and 
analysis  cells  to  attempt  to  determine  what  M&S  shortfalls  they  were  experiencing.  The  most 
critical  issue  that  was  brought  up  in  the  discussion  was  the  need  to  "feed  the  planning  and 
analysis  cells  with  GCCS  data  to  aid  in  the  development  of  courses  of  action  during  the 
exercise."  The  simulation  application  used  most  widely  by  the  USFK  warfighter  analysts  is  the 
Integrated  Theater  Engagement  Model  (ITEM).  As  this  model  had  already  developed  an  HE  A 
interface,  it  was  felt  that  extension  of  the  work  involving  GCCS-NSS  for  GCCS-ITEM  could  be  a 
straightforward  solution  to  the  GCCS  data  distribution  issues  for  planning  and  analysis. 

After  coordination  with  the  Defense  Threat  Reduction  Agency  (DTRA),  the  proponent  for  the 
ITEM  model,  a  task  to  replicate  the  capabilities  of  GCCS-NSS  using  ITEM  was  initiated  over  the 
summer  of  2001.  The  goals  of  this  task  were  to  develop  a  GCCS-ITEM  automated  initialization 
capability  that  could  be  used  on  a  trial  basis  as  part  of  exercise  Reception,  Staging,  Onward- 
Movement  and  Integration  (RSOI)  in  April  02,  with  full  implementation  planned  for  exercise 
Ulchi  Eocus  Eens  (UEE)  2002. 

5.1  GCCS-ITEM  Design 

Because  the  data  available  via  the  RTI  from  GCCS  is  relatively  fixed  (based  on  the  data  elements 
in  the  TDBM),  most  of  the  modifications  that  were  necessary  to  the  federation  were  done  on  the 
ITEM  side  -  not  on  the  GCCS  side.  Many  of  the  technical  issues  resolved  during  implementation 
with  NSS  were  carried  over  and  applied  for  the  ITEM  model.  This  included  the  development  of  a 
GUI  that  allowed  for  pairwise  matching  of  track  names  with  database  object  names,  and  the  use 
of  a  similar  set  of  procedures  for  initialization.  In  addition,  the  ITEM  user  associates  GCCS 
tracks  with  ITEM  objects  though  a  correlation  process,  and  then  performs  synchronization  to 
place  newly  correlated  data  into  the  ITEM  database. 

As  modifications  to  the  ITEM  HEA  interface  were  made  to  accommodate  the  reception  of  track 
data,  a  test  federate  was  provided  to  the  ITEM  development  team  (SAIC)  to  use  during 
component  testing.  The  Simulation  Integration  Test  Harness  (SITH)  is  a  component  developed 
by  the  MITRE  Corporation  that  allows  easy  emulation  of  other  federates  during  the  development 
process,  as  a  way  to  test  federates  under  development  without  the  need  for  the  actual  set  of 
federates  to  be  in  place.  This  component  was  provided  to  SAIC  for  development  testing  in  San 
Diego,  long  before  the  more  formal  integration  events  took  place.  The  use  of  the  tool  allowed  the 
SAIC  team  to  stimulate  their  ITEM  model  with  expected  GCCS  track  attributes  based  on  the 
EOM,  long  before  they  actually  participated  in  the  first  integration  event. 

5.2  Implementation  in  RSOI  02 

The  use  of  GCCS-ITEM  in  RSOI  02  was  to  be  limited  to  a  technical  demonstration  in  order  to 
test  run  the  application  in  an  operational  setting.  Thus,  the  focus  was  on  verifying  the  technical 
capabilities  of  the  federation  in  the  USEK  environment  and  not  on  use  as  a  COA  analysis  tool 
during  the  exercise. 


In  order  to  conduct  operational  testing  of  the  GCCS-ITEM  design  during  RSOI  02,  a  great  deal 
of  technical  development  was  completed  by  DMSO  (project  sponsor),  MITRE  (integration  and 
test),  NRE  (GCCS  Ambassador  developer),  and  SAIC  (ITEM  developer)  prior  to  the  exercise. 
Working  with  Operations  Analysis  Branch  (OAB),  USER,  the  design  team  began  building  the 
same  data  transfer  functionality  into  GCCS-ITEM  as  had  been  previously  demonstrated  with 
GCCS-NSS.  During  the  course  of  building  the  GCCS-ITEM  linkage,  the  design  team  began 
coordinating  with  the  USER  16  to  provide  the  necessary  security  documentation  to  physically 
connect  ITEM  with  the  GCCS  COP.  Coordination  with  the  16  required  the  design  team  to 
resolve  several  physical  and  technical  security  issues  in  accordance  with  the  procedures  outlined  in 
the  Defense  Information  Technology  Security  Certification  and  Accreditation  Process 
(DITSCAP).  A  critical  step  in  this  process  was  the  submission  of  a  System  Security 
Authorization  Agreement  (SSAA)  for  the  certification  and  accreditation  of  the  GCCS-ITEM 
linkage  from  the  GCCS  COP  through  the  federation  directly  to  ITEM.  Eor  RSOI,  the  SSAA  was 
not  processed  and  therefore  an  interim  technical  solution  was  required  that  met  all  the  security 
requirements  of  the  16.  Due  to  the  efforts  by  MITRE,  an  interim  authority  was  granted  to  operate 
the  GCCS-ITEM  system  via  an  “air  gap”  (see  Eigure  3).  This  air  gap  allowed  for  the  manual 
transfer  for  the  COP  track  information  from  GCCS  to  the  GCCS-ITEM  ambassador  system. 
With  this  solution,  the  design  team  could  execute  the  GCCS-ITEM  design  testing  during  RSOI 
with  an  interim  security  approval.  The  entire  system  setup  was  assessed  to  be  level  1  security 
(low  risk). 
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Figure  3.  Simulation  Architecture  for  RSOI  2002. 

As  described  in  detail  with  the  GCCS-NSS  design  the  capability  of  linking  analytical  models  to  the 
current  operational  situation  greatly  improves  the  wargaming  potential  of  any  warfighting  staff. 
Since  virtually  all  the  Combined  Eorces  Command  (CEC)  wargaming  is  conducted  with  analytical 
models  the  ITEM-GCCS  design  will  become  a  staff  multiplier.  As  demonstrated  with  the  GCCS- 
NSS  work  there  are  some  immediate  benefits  to  this  process  that  were  validated  during  RSOI: 

1.  Immediate  upload  of  the  COP  tracks  into  the  analytical  model  reduces  the  time 
required  to  “fat  finger”  or  manually  enter  the  data.  The  time  saved  not  only  allows  for 
more  opportunities  to  conduct  COA  analysis  but  it  also  avoids  information  latency.  In 
the  previous  manual  procedure,  by  the  time  an  analyst  loaded  the  data,  some  of  the 
information  may  be  so  obsolete  that  it  made  any  subsequent  analysis  invalid. 


2.  The  automated  system  of  uploading  the  data  avoids  mistakes  that  inevitably  occur 
when  manually  entering  data. 

3.  The  utility  of  ITEM  as  an  analytical  tool  is  greatly  enhanced  by  the  quick  refresh  of 
current  data.  Currently,  ITEM  is  used  as  a  stand-alone  analytical  tool  used  in 
deliberate  planning  and  not  within  the  context  of  a  model  assisted  wargame  for  the 
theater  staff.  Because  ITEM  has  the  potential  of  uploading  all  the  component  data 
(Air,  Ground,  Maritime,  and  Special  Operations  Eorces)  quickly  from  the  GCCS  COP 
the  USEK  planners  will  soon  explore  the  utility  of  ITEM  as  an  interactive  wargaming 
tool  for  COA  development. 

The  GCCS-ITEM  design  also  highlighted  other  critical  needs  in  the  CEC  automated  planning 
efforts.  CEC  is  currently  working  to  provide  the  Ground  Component  Command  (GCC)  with  a 
collaborative  planning  tool  to  conduct  wargaming  over  a  classified  distributive  network.  This 
tool,  developed  at  The  US  Army  Communications  Electronics  Command  (CECOM),  is  known  as 
the  Combined  Arms  Planning  and  Execution-Monitoring  Systems  (CAPES)  and  is  a  variant  on  the 
Battlefield  Planning  and  Visualization  (BPV)  and  DA  VINCI  planning  tools  already  demonstrated 
during  USEK  exercises.  As  the  command  struggles  to  develop  its  collaborative  planning  tools 
there  appears  to  be  a  definite  need  to  synchronize  the  distributed  wargaming  sites.  It  became 
obvious  to  the  CEC  staff  that  a  C4ISR-Simulation  realtime  initialization  capability,  like  the  one 
provide  by  GCCS-ITEM,  would  be  required  for  any  collaborative  planning  and  wargaming 
process. 

6.0  Near  Term  Plans 

6.1  Near  Term  Exercise  Applications 

Due  to  the  successful  introduction  and  use  of  the  GCCS-NSS  federation  during  Global  2001, 
plans  are  underway  to  install  NSS  and  the  GCCS  Ambassador  onboard  the  USS  CORONADO  in 
support  of  a  Joint  Task  Eorce  Exercise  (JTEEX)  in  late  Spring  2002.  The  CORONADO  will 
serve  as  command  ship  for  Commander,  U.S.  THIRD  Elect,  during  this  Abraham  Eincoln  Battle 
Group’s  (AEBG)  JTEEX.  The  GCCS-NSS  federation  will  be  used  in  a  similar  way  to  the  Global 
’01  application  -  allowing  rapid  initialization  of  NSS  scenarios  using  the  GCCS  Ambassador  to 
support  COA  analysis  and  decision-making.  However,  in  this  exercise,  NSS  will  be  used  to 
support  operations  in  a  more  realistic  non-laboratory  environment,  potentially  affecting  the  use 
and  employment  of  actual  physical  assets.  NSS  will  be  used  in  direct  support  of  the  Joint  Eorces 
Maritime  Component  Commander  (JEMCC)  and  plans  are  underway  to  provide  additional 
support  to  the  AEBG  Commander  and  his  Primary  Warfare  Commanders  (PWC).  While  details 
are  still  being  worked  out,  initial  plans  are  to  use  the  GCCS  Ambassador  onboard  the 
CORONADO  to  pull  in  the  GCCS  COP  and  initialize  NSS.  This  initialization  will  result  in  a 
baseline  scenario  within  NSS  that  will  be  sent  via  SIPRNET  email  attachment,  on  request,  to 
planners  and  decision-makers  onboard  the  USS  EINCOEN.  The  NSS  operator,  onboard  the 
EINCOEN,  will  provide  analyst  support  to  the  BG  staff  and  planners.  Only  a  single  instance  of 
the  GCCS-NSS  linkage  will  be  required,  resulting  in  the  generation  of  two  NSS  scenarios  that  can 
be  evaluated  at  different  locations. 

The  GCCS-ITEM  design  will  continue  to  be  refined  and  USEK  will  pursue  formal  security 
approval  in  time  for  application  in  Ulchi  Eocus  Eens  (UEE)  2002  -  thus  eliminating  the  “air  gap” 


requirement.  During  UFL  02,  USFK  plans  to  fully  employ  the  GCCS-ITEM  application  as  part 
of  the  COA  process.  SAIC  is  working  to  make  the  linking  of  COP  tracks  to  designated  objects 
more  automated.  It  is  expected  that  all  these  fixes  will  also  be  completed  prior  to  UFL02.  During 
the  exercise  the  GCCS-ITEM  design  will  enable  the  quick  turn  around  of  COA  analysis  required 
for  the  Naval  Component  Command  (NCC)  that  has  been  lacking  in  previous  exercises.  The 
maritime  analysis  section  of  OAB  will  conduct  most  of  this  work.  Additionally,  it  has  been 
briefed  to  MG  Miller,  CJ3,  that  efforts  would  be  made  to  test  the  feasibility  of  ITEM  as  a  CEC 
wargaming  tool  for  the  theater  staff.  Because  of  the  compressed  timelines  for  COA  development 
the  GCCS-ITEM  design  will  be  critical  for  this  effort.  By  quickly  uploading  current  information 
from  the  COP,  the  theater  staff  will  now  be  able  to  wargame  COA’s  in  a  more  responsive  manner. 
It  is  expected  that  the  design  itself  will  function  properly  and  that  the  major  obstacle  will  be  staff 
training  on  computer  assisted  wargaming  and  overall  ITEM  functionality. 

6.2  Dll  COE 

The  Defense  Information  Infrastructure  Common  Operating  Environment  (DII  COE,  or  just 
"COE")  is  a  software  environment  that  is  configuration  managed  by  the  Defense  Information 
Systems  Agency  (DISA)  with  the  intent  of  promoting  interoperability  and  re-use  of  major  C4ISR 
software  components  on  DoD  systems.  The  use  of  the  COE  is  mandated  by  DoD  within  the  Joint 
Technical  Architecture  (JTA)  [JTA,  2001],  so  that  all  C4ISR  systems  will  have  the  assurance  of 
running  under  a  common  configuration  managed  and  tested  environment.  It  is  also  intended  to 
provide  a  common  foundation  of  software  that  can  be  applied  across  a  wide  variety  of  end  user 
applications  so  that  individual  C4ISR  systems  ("Mission  Applications")  do  not  have  to  develop 
functions  that  are  already  available  in  the  COE. 

As  discussed  previously,  in  applications  such  as  GCCS-NSS  and  GCCS-ITEM  it  is  essential  that 
certain  M&S  applications  (such  as  the  HEA  RTI)  run  on  the  same  platform  that  the  C4I  system  is 
operating  on.  While  C4ISR  system  developers  may  be  willing  to  employ  such  M&S  components 
within  a  system  as  part  of  a  demonstration  or  prototype  effort,  it  is  unlikely  that  such  software 
will  be  fielded  unless  it  is  brought  under  the  configuration  management  (CM)  process  of  the 
C4ISR  system.  As  the  GCCS  Ambassador  and  RTI  have  been  shown  to  be  useable  across  a 
range  of  simulation  systems,  it  became  a  straightforward  decision  to  pursue  "segmenting"  both 
components  as  part  of  the  COE. 

Recently,  both  the  GCCS  Ambassador  and  RTI  have  been  modified  in  accordance  with  COE 
guidance  to  allow  for  submission  to  DISA  and  acceptance  into  the  COE.  This  process  is  being 
coordinated  through  the  COE  Modeling  and  Simulation  (M&S)  Technical  Working  Group 
(TWG)  which  identifies  M&S  requirements  for  the  COE  and  coordinates  implementation  of  new 
M&S  segments.  Both  the  RTI  and  GCCS  Ambassador  are  targeted  initially  for  use  as  COE- 
compliant  Mission  Applications,  under  GCCS.  The  eventual  goal  is  to  submit  a  commercially 
developed  version  of  the  RTI  into  the  COE  4.x  baseline  that  can  be  downloaded  as  part  of  the 
COE  software  suite  with  other  standard  C4ISR  applications.  This  should  eventually  lead  to  the 
ability  to  install  the  GCCS  Ambassador  and  RTI  directly  on  operational  GCCS  systems  for  use, 
rather  than  relying  on  the  use  of  a  separately  configured  Sun  machine  that  receives  forwarded 
OTH-G  tracks. 


6.3  Potential  Enhancements 


Among  the  enhancements  under  consideration  for  both  NSS  and  ITEM  are  the  transmission  of 
overlay  information,  interpretation  of  C2  messages  directly  by  the  simulation,  bi-directional 
transmission  of  data,  and  use  of  automated  UOB  tools  for  building  the  pre-application  simulation 
database.  All  of  these  enhancements  discussed  in  this  section  are  still  under  evaluation,  and  will 
be  implemented  pending  funding  and  prioritization  by  the  organizations  involved. 

Overlay  information  includes  graphic  data  that  appears  on  map  overlays  -  such  as  phase  lines. 
This  information  can  be  readily  generated  within  GCCS  as  part  of  the  tactical  picture  and  could  be 
transmitted  across  the  RTI  with  appropriate  extensions  to  the  FOM.  This  would  allow  for  a  more 
robust  set  of  data  from  GCCS  to  be  transmitted  across  for  COA  initialization. 

Another  area  that  warrants  potential  investigation  for  improvement  is  in  the  interpretation  of  C2 
data  directly  by  the  simulation.  In  its  current  form,  the  GCCS  initialization  process  is  able  to 
transact  the  "nouns"  from  GCCS  and  align  this  data  with  information  in  either  NSS  or  ITEM. 
However,  in  order  to  execute  a  COA  the  "verbs"  (i.e.,  orders,  enemy  intent,  etc.)  are  required  to 
be  able  to  direct  units  to  specific  locations  and  provide  them  with  the  appropriate  set  of  actions 
for  engagement.  Ideally,  this  could  be  done  via  the  C4ISR  system  so  that  an  NSS  or  ITEM 
operator  would  not  have  to  input  these  orders  into  the  simulation  as  part  of  the  initialization 
process.  Already,  three  sets  of  rudimentary  commands  from  GCCS  can  be  understood  by  NSS  -  a 
PIM  track  (Path  of  Intended  Movement),  Screen  Kilo,  and  Whiskey  Grid  -  had  been  implemented 
as  part  of  the  previous  GCCS-NSS  federation.  However,  to  simplify  the  COA  process  for  Global 
2001,  none  of  these  were  implemented  during  the  exercise. 

A  bi-directional  data  flow  would  not  only  allow  for  the  initialization  of  the  simulation  from  the 
C4ISR  system,  but  would  allow  for  the  playback  and  display  of  the  simulation  within  the  C4ISR 
system.  This  could  have  profound  impact  on  the  way  in  which  planning  information  is  distributed 
to  various  C4ISR  systems.  In  fact,  such  a  system  could  potentially  reduce  ambiguity  in  current 
text-based  planning  data. 

Another  areas  that  warrant  investigation  is  the  direct  database  build  of  a  simulation,  based  on  Unit 
Order  Battle  (UOB)  information  associated  with  the  scenario.  While  the  GCCS  COA  process 
allows  for  rapid  "alignment"  of  the  database  elements  in  either  NSS  or  ITEM,  it  does  not  address 
the  problem  of  building  the  database  from  scratch,  prior  to  exercise  execution.  The  use  of 
automated  UOB  tools  may  be  one  way  to  improve  this  process. 

6.4  Application  to  Other  Models 

While  any  simulation  that  is  HEA  compliant  could  in  theory  derive  data  from  GCCS  in  this 
manner,  there  are  only  a  select  few  that  are  used  in  the  execution  of  COA  and  deliberate  planning 
applications  that  really  need  this  capability.  The  Joint  Warfare  System  (JWARS)  is  one  of  the 
simulations  that  is  currently  considering  adopting  this  technology  for  use.  As  JWARS  has  a 
requirement  specified  in  its  Operations  Requirements  Document  (ORD)  for  operating  as  a  COA 
application  [JWARS,  1998]  in  support  of  CINC  analysis  requirements,  this  type  of  initialization 
scheme  may  be  well  suited  for  it.  JWARS  has  recently  developed  an  HEA  interface  for  use  with 
other  applications,  which  would  provide  a  straightforward  approach  for  implementation  with  the 
GCCS  Ambassador. 


7.0  Long  Term  Direction 


7.1  Additional  C4ISR  Data  Sources 

While  the  GCCS  COP  provides  a  significant  amount  of  information  on  enemy  and  friendly  units,  it 
does  not  contain  several  bits  of  data  of  interest  to  the  analysis  of  COAs.  Among  the  data  sources 
that  would  be  beneficial  for  inclusion  in  this  federation  are  the  Master  Intelligence  Database 
(MIDB),  Status  of  Resources  and  Training  Systems  (SORTS),  and  Joint  Operation  Planning  and 
Execution  System  (JOPES)  data.  Also,  since  GCCS  is  an  aggregated  view  of  the  entire  theater 
battle,  it  tends  to  lack  certain  detail  that  can  be  found  in  component  data  sources  such  as  Theater 
Battle  Management  Core  System  (TBMCS),  and  the  Joint  Common  Database  (JCDB). 
Implementation  of  COA  analysis  at  lower  echelons  may  require  finer  resolution  data  that  can  only 
be  found  in  these  component  C4ISR  systems. 

Over  time,  GCCS  is  planning  to  move  to  an  Integrated  Imagery  and  Intelligence  (13)  architecture 
that  will  incorporate  elements  of  the  MIDB  into  its  architecture.  This  information  should  in  turn 
be  available  to  the  GCCS  Ambassador  for  export  to  HEA-compliant  simulations  that  are  part  of 
the  COA  initialization  process.  Recently,  the  Army  TRADOC  Analysis  Center  (TRAC)  has 
developed  an  RTI  interface  to  the  JCDB  that  may  provide  a  way  of  initializing  applications  from 
that  data  source.  Other  solutions  for  accessing  MIDB  and  other  C4ISR  databases  via  the  RTI  are 
under  investigation. 

7.2  Reachback  Applications 

Analysis  simulations  have  been  used  for  years  in  a  "reachback"  mode  where  data  from  the  Theater 
is  typically  forwarded  to  an  analysis  center  for  incorporation  into  a  simulation  that  projects 
outcomes  over  the  next  hours  or  days.  In  most  cases,  the  data  that  is  transmitted  back  to  CONUS 
sites  consists  of  the  daily  CINC  briefing,  built  in  Powerpoint,  and  containing  representative  data 
on  the  current  theater  picture.  Eor  example,  during  UEE  00,  analysts  at  the  Army's  Center  for 
Army  Analysis  (CAA)  used  the  daily  CINC  briefing  to  perform  runs  on  their  Concepts  Evaluation 
Model  [Read  et  ah,  2001]. 

Extracting  data  from  the  CINC  briefing  and  inputting  it  manually  into  GEM  has  many  of  the  same 
problems  as  inputting  the  data  into  Theater  analysis  tools  such  as  NSS  and  ITEM.  A  more 
efficient  approach  would  be  to  export  the  C4ISR  picture  from  Theater  back  to  CONUS  where  the 
reachback  analysis  is  to  take  place.  Initialization  of  the  simulation  could  then  be  done,  on 
demand,  in  faster  time  and  with  fewer  errors. 

This  approach  has  the  advantage  that  different  simulations  that  are  HEA-compliant,  could  all  tap 
into  the  same  theater  picture  and  run  concurrent  analysis.  Different  analysis  centers  could  be 
focused  on  different  portions  of  the  operation  -  over  the  next  several  hours  or  over  the  next 
several  days.  Within  a  single  location,  multiple  instantiations  of  the  same  model  might  be  used  to 
conduct  multiple  runs  of  a  COA  concurrently,  in  order  to  generate  larger  sample  sizes  of  potential 
outcomes.  This  could  be  done  simply  by  federating  multiple  versions  of  a  model  to  the  RTI  to 
pull  data,  or  by  developing  an  architecture  that  provides  a  client/server  approach  similar  to  that 
discussed  above  for  the  GCCS-NSS  application  in  Global  01. 


7.3  Execution  Monitoring 


One  of  the  most  eompelling  ways  in  whieh  the  initialization  eapabilities  diseussed  above  eould  be 
exploited  is  via  exeeution  monitoring  of  operations.  Onee  a  simulation  is  "aligned"  via  the 
initialization  scheme  described  above,  and  the  appropriate  operational  plan  (OPLAN)  data  is 
loaded,  the  simulation  could  be  run  in  realtime  and  constantly  compared  to  the  C4I  picture.  The 
use  of  the  RTI  as  the  linkage  between  a  C4ISR  system  and  simulation  allows  for  straightforward 
implementation  of  such  a  scheme.  Once  data  has  been  used  to  initialize  the  simulation,  the 
simulation  would  then  publish  data  on  state  changes  of  its  units  as  it  runs.  In  fact,  since  the 
existing  GCCS-ITEM/NSS  FOM  distinguishes  object  class  by  “Real”  (published  by  GCCS)  or 
“Simulated”  (published  by  ITEM  or  NSS),  it  could  be  utilized  readily  for  such  a  purpose.  A 
monitoring  federate  attached  to  the  RTI  could  easily  track  inconsistencies  between  the  state  of  a 
unit  within  the  simulation  and  the  C4ISR  system.  Depending  on  the  threshold  set  by  the  user 
(distance  or  time  deviations)  an  alert  could  provide  a  commander  with  information  on  when  a 
particular  unit  is  "off  plan" 
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Figure  4.  Potential  Execution  Monitoring  Application. 

The  use  of  such  a  capability  would  not  only  have  implications  for  ensuring  that  Blue  forces  remain 
synchronized,  but  could  also  alert  planners  to  instances  when  Red  forces  deviate  from  the 
expected  tactics  that  underlie  the  OPEAN. 

One  of  the  most  interesting  aspects  of  such  a  system  would  not  just  be  the  alert  capabilities  that  it 
could  provide,  but  an  eventual  capability  to  determine  what  the  impacts  of  such  deviations  are 
within  the  OPEAN.  In  such  cases,  an  additional  simulation  could  be  federated  with  the 
applications  mentioned  above  and  run  in  a  faster  than  realtime  mode  to  perform  projections  based 
on  the  deviations  seen  across  the  system.  This  could  eventually  help  commanders  to  determine 
whether  or  not  deviations  in  unit  location  or  delays  are  important  enough  to  warrant  retasking. 


and  could  also  identify  opportunities  to  deviate  from  the  OPLAN  to  take  advantage  of  the 
evolving  operational  picture. 


7.4  Collaborative  Planning 

While  current  uses  of  the  GCCS-ITEM  and  GCCS-NSS  applications  are  focused  on  COA 
analysis,  there  is  no  reason  why  the  basic  components  of  this  technology  could  not  be  applied 
during  the  planning  phases  of  operations.  In  particular,  this  technology  could  have  significant 
impact  during  crisis  action  planning  -  where  no  OPLAN  currently  exists  and  the  current  C4ISR 
picture  rapidly  transferred  into  a  simulation  could  enable  faster  generation  and  analysis  of  a  crisis 
action  plan.  In  military  conflicts  such  as  operations  other  than  war  (OOTW)  and  military 
operations  in  urban  terrain  (MOUT),  where  crisis  action  planning  performed  more,  such  a 
capability  could  prove  invaluable.  One  possible  solution  here  would  be  to  pursue  a  GCCS 
initialization  capability  with  the  Joint  Conflict  and  Tactical  Simulation  (JCATS),  a  simulation 
tailored  for  analysis  and  training  of  OOTW  and  MOUT  missions.  JCATS  HLA  interface  may 
make  such  a  solution  straightforward  to  implement. 

The  rapid  transfer  of  C4ISR  data  to  a  simulation  used  in  planning  could  also  greatly  benefit  the 
refinement  of  existing  OPLANS.  By  initializing  a  theater-level  simulation  and  then  federating 
other  more  detailed  simulations  (such  as  signal  models,  intelligence  models,  and  logistics  models), 
the  impact  of  the  OPLAN  on  detailed  functions  can  be  determined  ahead  of  time.  The  use  of  the 
C4ISR  system  feed  to  obtain  the  latest  information  on  friendly  and  enemy  posture  to  refine  the 
OPLAN,  could  be  a  tremendous  asset  in  operational  planning. 

7.5  Joint  Experimentation 

Because  of  the  potential  to  improve  the  C2  decision  process,  a  potential  venue  for  use  of  this 
technology  is  in  joint  and  service  experimentation  events.  In  addition  to  the  major  joint 
experiments  such  as  Millennium  Challenge  02,  JLCOM  also  hosts  a  series  of  Limited  Objective 
Experiments  (LOEs)  that  are  smaller  in  scale  and  more  focused.  Such  events  could  be  ideal  for 
experimenting  with  rapid  COA  initialization  techniques. 

8.0  Summary 

The  application  of  the  GCCS-NSS  and  GCCS-ITEM  automated  initialization  schemes  is  an 
important  step  in  improving  the  utility  of  M&S  in  operations  planning,  analysis,  and  execution 
monitoring.  The  operational  utility  of  faster  initialization  of  these  models,  along  with  more 
accurate  transfer  of  data  has  been  demonstrated  in  exercises  such  as  Global  2001  and  RSOI  '02. 
The  use  of  standards  such  at  the  HLA  and  DII  COE  have  contributed  directly  to  implementing  a 
solution  for  data  transfer  between  C4ISR  and  simulation  systems  that  is  straightforward  to 
implement,  and  readily  extensible. 

Once  the  foundation  has  been  laid  of  moving  data  from  C4I  systems  into  simulation  analysis  tools, 
we  will  be  able  to  take  advantage  of  new  M&S  techniques  and  applications  that  can  provide  the 
warfighter  with  decision  support  aids  in  prosecuting  the  battle.  Solving  the  data  transfer  problem 
is  a  key  part  of  enabling  the  employment  of  execution  monitoring  applications,  collaborative 
planning  tools,  and  reachback  applications  for  the  warfighter.  Together,  such  tools  will  help  us 


achieve  the  vision  of  Transformation  and  Information  Superiority  documented  in  Joint  Vision 

2020. 
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